At 10:53 +0300 on 13/8/98, Aleksey Dashevsky wrote:
> (note, that each NULL is treated as new value, I mean one NULL is
> note equal to another one!)
Hey, wait a second. Wasn't this supposed to be fixed in 6.3?
I really hate the way nulls are treated in 6.2.1, and I'm pushing my
sysadmin hard to update the version, because I want sorts on two columns
not to be confused when there are nulls in the first column.
(That is, if I "ORDER BY heb_term, eng_term" - and there are possible NULLs
in heb_term, I expect all the nulls to be considered the same value, so
that all the rows with NULL in their heb_term will be sorted by eng_term.
Otherwise I have to make two separate queries).
I also want to be able to compare fields, and get a correct result if the
two fields are null. For example, I create two tables. The snapshot table
shows the rows in the original table, as they were at a given time, and I
want to be able to compare the row from the snapshot table with the
corresponding row in the original table, and see if anything has changed.
But if one of the fields is null, I would be comparing NULL to NULL, and in
6.2.1, it would look as if the two rows are different!
Anyway, I was sure this problem was fixed in 6.3.x... Can anyone confirm or
deny?
I do like the fact that I can have as many nulls as I need in a column with
a unique index. This should stay like that (I think we discussed it a long
time ago).
Herouth
--
Herouth Maoz, Internet developer.
Open University of Israel - Telem project
http://telem.openu.ac.il/~herutma